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© System for calling procedures on a remote network node. 



© A system for making procedure calls can be 
used with a network of computers. An application 
program on a local node calls a desired library 
procedure. The library procedure can be available 
on the local node or a remote node, and the location 
need not be known by the application. If the library 



procedure is available on a remote node, a remote 
router procedure communicates a procedure iden- 
tifier to the remote node. The procedure is executed, 
and any results are returned to the locol node, to be 
returned to the application program. 



CM 
< 

CM 
5 



CL 
LU 



SERVICE 
TABLES 



■ SERVICE 
ELECTOR 



f HOCCOWH 



-v-20 



INTERNAL 
SERVICES 



Fig. t 



26 



28 



Xerox Copy Centre 



BNSOOCID: <EP 0414624A2J_> 



EP 0 414 624 A2 



"** ° ALLING "»««» <* * DEMOTE NETWORK NOOE 



Tbe present invention relates oenerafiv tn ™ 

procedures. ein as 

wit h D S" S °/ Pr0 ° edUre Ca " in 9 inventions differ 
mth different programming lanquaaes s„l 
rarneters may be passed » 

different languages, procedure calls must be made 
to procedures originally written in the 
guage, or another language using the same cal fno 
conventions. If it i s desired to make a cainl ! 
procedure originally written in a differen , a u L 

special steps can sometimes be taken r«e#r 
ture the c a ,, to function correct, wt^C^ 

Ton of * T tUr ' n9 USUa,,y "Odifica. 

In many computer systems, including virtual 
iTo^r*™ *> SySt6ms ' -mmon ! 

ofte r Ur ? re maimained f0r standa * and 
often used functions. These procedures som P 

<mes referred to as system services a e ZZ 

from application programs, freeing an apla«o " 

programmer from writing and debugging cod e "o 

EetlT™ 'r ti0nS - Ll ' b -V Actions c n 
they mat t h" aPP " Cati0n e r °9™ « »nk time, or 
hey may be dynam.cally linked at execution time if 
this is supported by the operating system. 

scribed 6 if n 9Ua9eca,,in 9 ^emion Problem de- 
scribed above ex,sts with the use of procedure 

en in each language supported by the system so 
alTb f e f Pr0CedUreS SXiSt for Perming the 
or a lim S T a,temative is to h ^ °ne 

partL artn ""^ ° f Pr0Cedures ^ a 
part.cular language, and require applications Dm 
grammers to perform whatever steps a nec e T 
™er toe,, procedures written inVffelt 

When several computer systems are connect- 
ed together through a local network, it is des ab 
to share resources as much as possible. This Is 



generally not feasible for library procedures bp 

„ VU,VJ lu,l,IBr °e desirable for such a 

system to allow the applications programs to J 
library procedures without knowing wSher the" 
are coated on the local network'node o on a 

a?s to T' H W ° Uld a,S ° be dSSirable to -ch 
calls to be made to procedures written in a Ian- 

Sut^r*"! procedure ca,,in9 

tas bLnn h , S,,V ° f ' angUa 9 e Specific ^nsla- 
» t nlT* ^ aPP "' Cati0nS prc ^™- 

to oZl a " ° bieCt ° f ,he Present Mention 
aoZT 2 SyStem and method wh 'ch allows 
applications programs to make calls to library pro- 
cedures wh,ch can be located on remote machines 
connected to a local machine by a network 

ornv h! S I ^ ° bieCt ° f the Dresen( invention to 

ZTJT 3 SySt6m and meth <* **h allow 
applications programs to make calls to library era- 
sures Wth0ut ^o-ing whether such lib a y o o- 

It is a further object of the present invention to 
provide such a system in which calls to a bra v 
Precede can be made from application 

35 IT, 2 9 3 diffSrent procedure calling conven- 
es tion from that used by the library procedure 

svstem'rn aCC ° rdin9 f ° the Present '"venBon. a 
able ,ocally or on a remote machine. Locally aval- 

Results are returned to the .ocal machine for se 
by the applications program 

The novel features believed characteristic of 
the invention are set forth in the appended claLs 
» The invention itself however, as well as a pre e ^' 

the°reof° f Tk "* ^ ° bjeCtS and ^9 
hereof, will best be understood by reference to the 

£5ZT W descrip (ion of an 

bod ment when read in conjunction with the accom- 
panying drawings, wherein: 
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Figure 1 is a block diagram of a system for 
calling library procedures on a local machine; 
Figure 2 is a diagram illustrating a format for 
calling library routines; 

Figure 3 is a flowchart illustrating steps taken to 
call a library procedure on a local machine; 
Figure 4 is a block diagram of a system for 
calling library procedures on a remote machine; 
Figure 5 is a flowchart illustrating steps taken to 
make a synchronous call to a library procedure 
on a remote machine; 

Figure 6 is a flowchart illustrating steps taken to 
make an asynchronous call to a library proce- 
dure on a remote machine; 
Figure 7 is a flowchart illustrating steps taken to 
initiate a communications link for a series of 
calls to library procedures on a remote machine; 
and 

Figure 8 is a flowchart illustrating steps taken to 
terminate a communications link for a series of 
calls to library procedures on a remote machine. 

The system described herein is suitable for 
use with nearly any general purpose digital com- 
puter. Mainframes, minicomputers, engineering 
workstations, and many desktop personal comput- 
ers can support the system described below. Only 
minor modifications, within the ability of those 
skilled in the art, are needed for various existing 
language compilers as will be described below. 

The terms library procedures, services and ser- 
vice procedures are used synonymously. Local 
node and local machine mean the computer on 
which an applications program is executing. Re- 
mote node and remote machine mean a computer 
which is connected to the local node by a commu- 
nications link, such as a local area network. 

Referring to Figure 1, a system 10 for handling 
library procedure calls which are available on the 
local node includes a service director 12. The 
service director 12 is a software procedure which is 
called by a stub procedure 14. The stub procedure 
14 is part of an application program 16. 

The service director 12 contains several proce- 
dures which define internal services 18. The ser- 
vice director 12 also has access to data structures 
which define service tables 20. While executing, 
the service director 12 can make procedure calls to 
library procedures 22, 24, 26, and 28. 

The application program 16 can perform any 
end use or system function, and is typically written 
in a high level language such as C or COBOL. 
Decreasingly, the application 16 may be written in 
assembly language. The stub procedure 14 is a 
small procedure which is linked to the application 
16 at link time. 

The stub procedure 14 is called in the manner 
of any other procedure by the application 16. Pa- 
rameters passed to the stub procedure 14 describe 



a system library procedure, or service, which ex- 
ecution is desired. The stub procedure 14 uses 
these parameters to make a procedure call to the 
service director 12. 

5 Since different programming languages use dif- 

ferent procedure calling conventions, a different 
stub procedure 14 must be provided by the system 
for each programming language supported. How- 
ever, a single stub program 14 makes all calls to 

w the service director 12 for all desired library ser- 
vices. 

The service director 12 is the interface used by 
application programs 16 when library procedures 
are called. The service director 12, when called, 

is examines the parameters passed to it and deter- 
mines which library procedure is to be invoked. 
Certain procedures are preferably included directly 
in the code of the service director 12. These proce- 
dures can be referred to as internal services 18. or 

20 environmental services. These procedures 18 are 
typically those which are executed often, and are 
not of great complexity. Efficient calls to these 
procedures 18 are preferred in order to prevent 
system performance degradation. Typical system 

25 services which can be included as internal services 
18 to the service director 12 include program and 
storage management, time of day and similar sys- 
tems services, and initialization and control routines 
directed toward operation of the service director 12 

30 itself. 

When an application 16, through the stub 14, 
calls the service director 12, a procedure to be 
performed is identified by parameters passed 
thereto. Once the desired procedure is identified, 

35 the service director must determine where the pro- 
cedure is stored in the system, what parameters it 
requires, and the language the procedure was 
originally written in. This last item indicates the 
procedure calling convention which must be used 

40 when the desired library procedure is invoked. The 
service director 12 finds this information from the 
service tables 20. The service tables 20 are data 
structures which provide a mapping from the 
names of system library procedures to the informa- 

45 tion just described, and can be implemented in any 
of several well known data structures. 

Once the service director 12 has identified the 
library procedure to be invoked, it arranges any 
parameters to be passed thereto appropriately for 

so the calling convention expected by the procedure, 
and then calls it. Any results returned by the proce- 
dure are passed to the service director 12. If nec- 
essary, the service director 12 reformats the re- 
sults, and returns them to the stub procedure 14. 

55 In many instances, an application program 16 

and a called library procedure will be written in the 
same language, so that little difficulty is encoun- 
tered in making the required procedure calls. In 
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other cases, an implementation of one language 
may pass parameters and return results in reo7 
ters. wh ,le an implementation of another iLLf 
cou d use a stack. The service director T 2 "S? 
what ,s necessary to translate between one callina 
convention and another, and makes these h an es 
a fairly straight forward manner. For examT 
data and pointers can be moved from register Z a 
stack, and vice versa. «9>sters to a 

In a preferred embodiment, an application must 
make an initialization call to the service dt ct0 M 2 

This call passes parameters which identify the ao- 
Ptatton. and allow the service director 12 to 0C ate 
the appropriate service tables 20. Differ J™? 
t-ons may use different sets of service' tableTTh^' 
ca can also provide a pointer to a commotconS 

It is also preferable for the application ,6 to 
make a term.nat.on call to the service director 12 
after a , calls to Horary procedures are comp e , ed 

areaV f ^ 12 to *» ««S 

Figure 2 illustrates a typical command for use 
"Jr. the application ,6 for invoking a library Z- 
cedure. A command line 40 is a call to I J b 
P ocedure ,4 having a stub procedure name 42. n 
some languages, such as FORTRAN, the word 

invoking the stub procedure ,4. In many other 
anguages, the word CALL is not used, and the 

ntm b e P 42 CedUre " " ^ * «4>* 

The stub procedure name 42 is preferably rela- 

rus: r or a dT so ; hat * tends to ^ ^ 

he use of descr.pt.ve procedure names. In order 
hat a system linker will be able to link in the stub 

program 16. the stub procedure name 42 indicates 
which language is being used . In Figure 2 a is 
shown, a d this _ ,. s preferab|y 9 ^ * 

more characters indicating the language being 

9 uaoe> " " ASM " «°< a ^mb.y L 

Quage). In the alternative, the same stub procedure 

Sir for a " ,an9uages ' - d ^°oZZ 

Dlacino th PPr0Pnate StUb Pr0cedure by 

in Zo^T7 y external linkage info ™«™ 

m the object file .t creates when it compiles the 
application program 16. <-ompi.es the 

dure' 14 f ; r s St a Parameter P3SSed to the ** proce- 
dure 14 ,s a serv.ce parameter 44, which is a 

Z V T h d3ta StmCtUre Ca,led a ~*» name 3 
block 46. The second parameter to be passed is a 
common block identifier 48, which contains a post- 
er to a common block 50. The third parameter 52 



is a pointer to a procedure block 54, and additional 

ssrw each ~se P aS:r 

5 hr J*? Parameters 52 and 56, shown in square 
' o ackets, are optional in some cases. That is some 
"J™- service calls, such as time of * y may 
require only the parameters 44 and 48. deoend^na 
upon implementation. ^Pending 
The service parameter 44 points to the **n,;~ 

name block 46. which is an'a.lo aS b. c 0 
memo ining severa( ^ <oc of 

umhT- ^ nUmberS Sh ° Wn in b,0ck 46 indicate 

preyed pi'? 3 that fie ' d OCCU > ies - *> 'he 
preferred embod.ment. the first field in 

" theTota,' 00 " ? fS 3 LENGTH ,ie ' d ' -hichTnd^: 
the tote, number of bytes in the service name block 

name nt ^ * 3 NAME field ' which '» «he 

name of a serv.ce. A PARM COUNT field indicates 
the number of parameters which are to be passed 
» to the called service. This count is use to de er- 

ZJUXS Pr ° CedUre ParamSter 52 * X 

? s th„ 1 F k LAGS fie ' d iS US6d to pass information'from 

OnV Pr T dUre U t0 thS SSrvice di "*tor 12 
une type of .nformation typically passed is the 
|dent,ty of the calling language.^ o 7L , tub 
procedures 14 for different languages call the ser- 

£ « J" S6rViCe name block indi "tes to 
thence director 12 which calling convention is 

The INDEX field is used to more quickly iden- 

» 1 vil P TT ° f inf ° rmati0n abo * a P^cular 
service. The first time a service is invoked the 

tables 20 ,n order to match the NAME field with the 
various names available in the tabfes 20. Once ii 
match has been made, the service director 12 
Places an identifier for that entry in the tabes 20 
into the INDEX field. The identifier car Z T for 

a table. Whenever various functions of this service 
« aTce" 1 the'" fUtUrS ' th '' S ^ is - d 

HTsX appropnate en,ry in the service tab,es 

director SZ™? **** 5 ° ' S US8d by the serv 'ce 

lTZ " StatUS 3nd ° ther informa «°n to 

tne application program 16. A LENGTH fi*M i„ 

TURN CODE field ,s used to return status codes to 
the ap P ,,cat.o n program ,6. By convention in 
preferred embodiment, a positive value for the re- 
turn code simply passes through any return code 
ss generated by the called library procedure. Also by 

used bTth 3 ne9atiVe Va ' Ue f ° r 3 return c ° d * i 
used by the serv.ce director 12 to indicate a failure 

withm ,ts area of responsibility. Such failures could 
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include, for example, the inability to locate a de- 
sired library procedure. The EXTENDED CODE 
field provides an additional ability to return error 
codes. 

The ADDITIONAL ELEMENTS fields are op- 
tional, and may be used to transfer data or pointers 
to data back to the application program 16. 

In addition to the LENGTH field, the procedure 
block 54 includes a FUNCTION CODE field. This 
field is a number indicating which function of a 
service is desired. 

In a preferred embodiment, it is anticipated that 
related functions will be grouped together, and this 
grouping is called the service. In order to access 
one of these procedures, a name applied to the 
service as a whole is required, and is found in the 
service name block 46 r and an indication of which 
procedure within the service is requested is found 
in the procedure block 54. For example, a group of 
routines for performing matrix manipulation can be 
identified by a single service, with the procedure 
block 54 indicating whether calculation of a deter- 
minant, matrix multiplication, inversion, or other 
matrix manipulations are requested. 

Each parameter block 58 is used to transmit 
one parameter to the requested library procedure. 
The SERVICE DATA field in the parameter block 
58 can contain the data directly, or can contain a 
pointer to the data. The type of data contained in 
each parameter block 58 is dependent upon what 
each individual library procedure expects, and will 
be specified in the documentation for that particular 
library procedure. 

Figure 3 illustrates the steps which occur dur- 
ing a call of a library procedure, which is available 
on the local node, by an application program 16. 
The flowchart of Figure 3 assumes that any initial- 
ization calls which need to be made to the service 
director 12 have already been made. Figure 3 
illustrates only the sequence of events which occur 
during a single call to a library procedure. 

First, the application program 16 calls the stub 
procedure and passes parameters to it 70. These 
parameters, as described in connection with Figure 
2, preferably identify at least a service and com- 
mon block, and optionally a procedure identifier 
and parameters if required. The stub procedure 
then sets a calling language flag 72. This flag 
indicates to the service director 12 the program- 
ming language of the application program 16, 
thereby indicating which calling conventions are 
used by the application 16 and stub procedure 14. 

The stub procedure then calls the service di- 
rector 74, which determines if the request is for an 
internal service 76, If the requested procedure is 
not internal to the service director 12, the service 
director 12 locates the desired procedure in the 
service table 78. As described above, the service 
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table entry indicates that information necessary for 
the service director 12 to properly call the re- 
quested library procedure. In the method of Figure 
3, the service table entry indicates that the desired 

5 procedure is available on the local node. 

The service director 12 then sets up the pa- 
rameters to call the library procedure 80, and calls 
it 82. The service procedure executes in its normal 
manner 84, and returns any generated results to 

io the service director 86. 

The service director 12 sets up its return pa- 
rameters 88 to match the calling convention of the 
application program 16 as indicated by the flag set 
in step 72. The results are then returned to the 

75 stub procedure 90, which in turn returns them to 
the application program 92. 

In step 76, if the service director 12 detects 
that an internal service is requested, it executes 
such internal procedure 94 and goes to step 90. 

20 The service director 12 understands the parameter 
passing mechanism used by the application pro- 
gram 16 because of the calling language flag set in 
step 72, and can handle any required translation 
directly. 

25 Figure 4 is a block diagram of an embodiment 

of the system in which an application running on 
one node of a network can call a service procedure 
on another node of the network. The system shown 
in Figure 4 can be used for operation in several 

30 different remote modes, which are separately set 
forth in the flowcharts of Figures 5-8. For ease of 
understanding, not all of the details shown and 
described in connection with Figure 1 are included 
in Figure 4, although a preferred embodiment uses 

35 the same techniques. 

Referring to Figure 4, an application program 
100 invokes a service director 102 through a proce- 
dure call 104. The service director 102 invokes a 
remote router service 106 with a procedure call 

40 108. The remote router service 106 is a iibrary 
procedure which sets up remote communication 
with a remote node connected to the local node 
through a network. 

The remote router 106 communicates with a 

45 network interface 110 in order to transfer data and 
results over the network. The network interface 110 
represents all of the hardware and software inter- 
faces and connections necessary to connect 2 
nodes in the network. Network architectures differ 

so greatly from each other, and the details of network 
linkages do not form a part of the present inven- 
tion, so details of the network interface 110 are not 
shown. The remote router service 106 also commu- 
nicates with a data mapper 112, which controls 

55 formatting of messages transferred over the net- 
work. A remote router response procedure 114 
communicates with the network interface 110 in 
selected situations. In these situations, the re- 
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»*n into a queue Tie ST n ° de ' M P ' aces 
application ,o I "1^ **** * V the 
-nica.es with £ S^^"*""' 
interpret the format of th/ f order t0 

-ormat them ^L^Z JT" ^ 
tion 100. ^ecrea by the appj/ ca - 

This data descriht a netWOrk interface "0. 

application procedure % rSm ° te router 

data mapper S t fhl COmmunic ^s with a 

nication stream, and'invokesT^n C ° mmu - 
«th a procedure call " 24 !, ^ 122 
remote router anJ.J 6 remote node - «he 

service doctor Sf° n Pr ° CedUre 118 the 

"ice procedure as de scrL 3 ser ' 

^e 1. The servicfdi t 122 IT*" With 
-9 convention translation! w Z Ca "" 
and invokes a reouesteH «, necessary 
When tt» ' Ce P roc edure 124 

wnen the requested procedure 15* t = 
it returns a result if am I T te rmmates, 
122. which in turn re Lrn S th $erV ' Ce direct °r 
t- Procedure 8 Ca p oc e r Ulf * ^ applica ' 
application procedure , ,8 COm 6 r6tUm ,2a The 

nication over the network and ^ C ° mmU - 

"a can be returned o' etl?" Pr ° CSd ^ 
^ placement into L^TTerT^ 
be returned directlv tn «, * they can 

procedure 106 ^1^ rem ° t9 
cedure 106 returns he ret ,s Tin * ^ ^ 
tor with a procedure return 30 h ^ direc " 
a procedure return ,21 ? ' Ch in tUrn uses 
application %o ^ * retUrn the results ,0 me 

service 126 ca i be t n ° deS ' The ' e ™e 

technique^m; n ; 9 ClTci 
waits until results are rli al,,n9 W^lion 

Remote seS Z^TsT^ 
"asynchronous" manner mt ' nV ° ked in an 
«on continues to peXmZ ^ * *" ^ 
the remote node inSes hT ^i" 9 whi,s 
and fetches the res^^V"" 08 procedufe ' 



time a remote call is made or a <,,„„! 
can be set uo fnr ngle cor| nection 

calls. MakLg a new cn^ T* d " ftWnt 
5 call 9 enera„? l^TS^ ™ 
5 up the connection, but avoid, T Sett,n9 
communication links 0 fZ ! " 9 dedicated 

communications link for several ll! 9 S ' n9 ' e 
invocations can be refL rt ? te P roce d"re 

» request with sIart^Op " ^ 3 rem0te 

serv ces, the rpmnfa "uaes. f-or remote 

municate with fhe r*™ * sed t0 con > 

Parameters l^r^o 33 ^ 
dures, are stored in ml ^ f remote P^ce- 

* wil, know how 0 format h 112 50 that « 

vw j IUW t0 rormat and extract data 

mun,cations with the remote no^e Thf ° 0m ' 
mapper I2n ie Tne rem ote data 

remote ro L STJ^ '" hen 
ized in Ser t0 en/h 0 " tK ° CMun 118 is 

t^e appiication P ro^oT^V: 
vice director 150 ann „ f e local ser " 

35 as descried fn P SS6S Meters thereto 
aescribed in connection with Fionre 0 
service director 102 searrho* -7 9 2 ' Tne 
locates the entry £Z Serv ' ce tab,es and 
services which II dl ! Service ' F °r 

« service dirTc onoi th ' CS ta5 ' es 152 ' Th « 
service 154 ^ ' nVOkeS ,he remo ^ router 

As described above a data ™„„ 
was associated witf^ each fLT^ ^ 112 
service tables at the H^ h ° te S6rvice in the 
« defined The da ' rem ° te services w «re 

identifier I d P TZZ% '? r6adieS the Service 
network i 56 Taet o 1 Sm '' SSi ° n 0Ver the 
appropriate ^ L 9 communi cations blocks 

not be transfe'ed The T* b '° Ck 50 need 

trfies wrdnS. 7 ^? 11 maPP8r 112 a,S0 iden - 

-ed ,0 correct eiactTheT ? ^ 06 
ss eters. f the ^nsferred param- 

«on Procedu e , S T ° he d e at r° n e 3PP ' iCa - 

f o- i ne data, wh (C h includes the 
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service procedure to be invoked and all necessary 
parameters, is then sent over the network 160, and 
received by the remote router application proce- 
dure 162. Since this is a synchronous call, the 
remote router service 106 at the local node then 
waits until it receives a reply 164. 

At the remote node, the remote router applica- 
tion 118 communicates with the data mapper 120 
which extracts the data 166. Using the service call 
identifier and parameters extracted by the data 
mapper 120, the remote rcuter application 118 
invokes the service director 122 as does any other 
application 168. The service director 122 calls the 
appropriate service procedure 170, which executes 
in the normal manner 172. Upon completion, the 
selected service procedure 126 returns its results 
to the service director 1 74, which in turn returns its 
results to the remote router application 176. 

The data mapper 120 then readies the results 
for communication over the network 178, and the 
remote router appli cation 118 returns the results to 
the remote router service 180. Once the remote 
router service 106 has received the results 182, the 
remote router application 118 terminates 184. The 
data mapper 112 extracts the results 186 into a 
format understood by the service director 102, and 
returns them to the service director 188. Service 
director 102 then in turn returns these results to the 
application 190, which continues processing. 

A preferred method for making an asynchro- 
nous remote request without START/STOP is 
shown in Figure 6. The application program calls 
the service director 200, which identifies the re- 
quested service procedure as a remote service in 
the service tables 202. The service director then 
calls the remote router service 204, which commu- 
nicates with the data mapper in order to ready the 
service procedure identifier and parameters for 
transmission 206. A connection is then initiated to 
the remote node in order to establish a commu- 
nications link 208, and the data describing the 
remote service procedure and its parameters is 
then sent to the remote node 210. When the re- 
mote router application at the remote node re- 
ceives the data 212, the local remote router service 
executes a procedure return to the service director 
214, which in turn executes a return to the calling 
application 216. The application then continues 
processing 218, and can check for returned results 
in the queue 1 16 at a later time. 

When the remote router application 118 re- 
ceives the service procedure and parameter data 
212, the remote data mapper, which was identified 
by .the data mapper 112 at the local node, extracts 
the procedure identifier and parameters 220. The 
remote router application then, acting as any other 
application program, calls the service director 222, 
which calls the appropriate service procedure 224. 
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The service procedure executes 226 and returns 
any results to the service director 228. The service 
director returns the results to the remote router 
application to 230, which formats them for trans- 

5 mission over the network by communicating with 
the mapper 232. 

Since this was an asynchronous request, the 
results are not returned to the remote router ser- 
vice 106 at the local node which originally re- 

w quested execution of the service procedure. In- 
stead, when the data is sent (step 210) to the 
remote node, the transaction is identified as an 
asynchronous call, and a remote router response 
procedure 114 is identified to which the results 

15 should be returned. 

Therefore, the remote router application 118 
initiates a connection to the identified remote router 
response procedure 234. Once the connection is 
established, the results are sent to the response 

20 procedure 236. Once the response procedure 114 
receives the results 238, the remote router applica- 
tion 118 terminates 240. The data mapper at the 
iocal node then extracts the results 242, and the 
response procedure places them into the queue 

25 244. At some later time, the application program 
retrieves the results from the queue 246, and con- 
tinues processing. If the results have not yet been 
placed in the queue 1 16 at the time the application 
program 100 tries to retrieve them 246. the applica- 
nt) tion program can either wait until the results are 
available, or continue further processing and try 
again at a later time. 

As described above, START/STOP transactions 
can be used to minimize the overhead required to 

35 set up the communications links between the local 
and remote nodes. In the methods described in 
connection with Figures 5 and 6, a new network 
communication link must be set up each time a 
remote service procedure 126 is invoked. If an 

to application program 100 knows that multiple con- 
secutive invocations of a single or related service 
procedures 126 will be made, it is more efficient to 
set up a single communi cations link between the 
nodes and utilize that link for several transactions. 

45 Figures 7 and 8 show a preferred method for 
initiating and terminating a series of START/STOP 
transactions. The applications program 100 initiates 
a series of START/STOP transactions, performs the 
transactions in a method very similar to that de- 

50 scribed above, and finally terminates the series. 

Since the system described herein is transpar- 
ent to the application program 100, it will often not 
be known whether a particular requested service 
procedure is performed locally or on a remote 

55 node. Therefore, an application program 100 can 
initiate and terminate a series of transactions as if 
they are remote service procedures. If the service, 
director, through searching the service tables, de- 
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mote node routing procedure, wherein a procedure 
corresponding to said desired procedure is called 
by said remote node routing procedure and returns 
a result thereto. 

2. The system according to claim 1 , characterized 
in that it further comprises : 

a first interface callable by the application program 
in a standard format, wherein said first interface 
calls said local node routing procedure if the de- 
sired procedure is located on a remote node; and 
a second interface callable by said remote node 
routing procedure in a standard format, wherein 
said second interface calls one of said plurality of 
procedures corresponding to the desired procedure 
identifier received from said remote node routing 
procedure. 

3. The system according to claim 2, characterized 
in that it further comprises a first table connected 
to said first interface for indicating whether the 
desired procedure is available on the local node or 
a remote node; and 

a second table connected to said second interface 
for indicating the location of and procedure call 
requirements for calling the desired procedure from 
said second interface. 

4. The system according to anyone of the claims 1 
to 3. characterized in that it comprises : 

a queue for holding results returned from said 
remote node routing procedure for later availability 
to the application program, wherein the returned 
results are placed into said queue. 

5. The system according to anyone of the claims 1 
to 3, characterized in that the results returned by 
said remote node routing procedure are returned to 
the application program by said local node routing 
procedure. 

6. A method for calling a procedure from an ap- 
plication program, characterized in that it com- 
prises the steps of : 

calling a routing procedure on a local node from 
the application program with a desired procedure 
identifier; 

calling a routing procedure on a remote node from 
the local node routing procedure with the desired 
procedure identifier; and 

calling a procedure on the remote node corre- 
sponding to the desired procedure identifier. 

7. The method according to claim 6, characterized 
in that it further comprises the steps of : 
returning a result from the desired procedure; 
returning the result to the local node routing proce- 
dure; and 

returning the result to the application program. 

8. The method according to claim 7, characterized 
in that said step of returning the result to the 
application program comprises the steps of: 
placing the result in a queue accessible by the 
application program; and 



reading the result from the queue into the applica- 
tion program. 

9. The method according to anyone of the claims 6 
to 8, characterized in that a new network commu- 

5 nications Sink is established each time a desired 
procedure is called on a remote node. 

10. The method according to anyone of the claims 
6 to 8, characterized in that it further comprises the 
steps of: 

ic prior to making a series of desired calls to a 
procedure on a remote node, establishing a net- 
work communications link between the local node 
and the remote node; and 

maintaining such communications link during the 
is series of calls. 

11. The method according to anyone of the claims 
6 to 8 characterized in that said first calling step 
comprises the steps of: 

calling a first interface on the local node from the 
20 application program with the desired procedure 
identifier; 

determining whether the desired procedure is avail- 
able on the local node or a remote node; and 
if the desired procedure is available on a remote 
25 node, calling the local node routing procedure with 
the desired procedure identifier. 

12. The method according to claim 11, character- 
ized in that said step of calling the routing proce- 
dure on a remote node comprises the steps of: 

30 calling a second interface on the remote node from 
the remote node routing procedure with the desired 
procedure identifier; and 

determining a procedure corresponding to the de- 
sired procedure. 

35 
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